### Rozdział. Monitoring i alerting po starcie – jak mieć „rękę na pulsie” i szybko reagować

Kiedy strona już działa, Twoja praca się nie kończy – po prostu zmienia charakter. Od tej chwili najważniejsze są stabilność i szybka reakcja na problemy. Użytkownik nie musi wiedzieć, że coś poszło nie tak. Ma trafić, wykonać akcję i wyjść zadowolony. Ty masz mieć „radar”, który wykryje awarie, błędy i spadki wydajności zanim zauważą je klienci. Ten rozdział pokazuje praktyczny zestaw monitorów (od dostępności po błędy JS i Core Web Vitals) oraz prostą procedurę „kto-co-kiedy”, by każdy incydent zamykać szybko i bez chaosu.

#### Co monitorować na co dzień: cztery warstwy spokoju

1) Uptime – czy strona w ogóle odpowiada
- Po co: nawet krótka niedostępność oznacza utracone wizyty, leady i zakupy. Uptime ma wykrywać awarie w minutach, nie godzinach.
- Jak: ustaw monitoring HTTP(S) z zewnątrz (np. UptimeRobot, Better Uptime, Pingdom).
  - Częstotliwość pingu: 1–5 minut.
  - Lokalizacje: co najmniej dwie (Europa i USA), aby uniknąć fałszywych alarmów.
  - Progi alertów: „zgłoś, gdy 2 lokalizacje kolejno nie odpowiadają”.
- Alerty: e‑mail i SMS/Slack. SMS dla krytycznych awarii (HTTP 5xx, brak odpowiedzi), e‑mail dla ostrzeżeń (czasowo długi TTFB, pojedyncze timeouty).

2) Alerty błędów serwera (5xx) – problemy po stronie backendu
- Po co: kody 5xx (500, 502, 503, 504) to błędy, których użytkownik nie „ominie”. Trzeba wiedzieć, kiedy i gdzie się pojawiają.
- Jak: skonfiguruj zbieranie logów serwera lub użyj aplikacyjnego monitoringu (New Relic, Datadog, Sentry Performance dla backendu).
  - Ustaw alert, gdy liczba 5xx w 5 minut przekroczy próg (np. 5–10 zdarzeń) lub wzrośnie o X% względem mediany.
  - Loguj URL, metodę, user-agenta i korelację z wdrożeniem (tag release) – przyspiesza diagnostykę.
- Dodatkowo: włącz „synthetic checks” najważniejszych ścieżek (np. otwarcie koszyka, wysłanie formularza), które wykryją błąd działania konkretnej funkcji, nawet jeśli strona „wstaje”.

3) Błędy JavaScript (frontend) – to, czego nie widać w logach serwera
- Po co: dla użytkownika błąd JS to „strona nie działa” – przycisk nie reaguje, formularz się nie wysyła. Serwer może nic o tym nie wiedzieć.
- Jak: użyj narzędzia do śledzenia błędów klienta (Sentry, Bugsnag, Rollbar).
  - Włącz source maps, by widzieć prawdziwe linie kodu.
  - Grupuj błędy według wydania (release) i przeglądarki/urządzenia.
  - Ustaw alerty: nowy błąd o wysokiej częstości, nagły wzrost błędów krytycznych, błąd w najnowszym release.
- Co dajesz zespołowi: stack trace, kontekst (URL, user agent), „breadcrumbs” akcji użytkownika i procent dotkniętych sesji.

4) Core Web Vitals i wydajność – czy strona nie zwalnia po czasie
- Po co: wydajność wpływa na SEO i konwersję. Strona zwykle „tyje” z każdą zmianą – trzeba trzymać dietę.
- Dwie perspektywy:
  - RUM (Real User Monitoring) – rzeczywiste dane od użytkowników: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift). Źródła: CrUX (Chrome UX Report w Search Console), Sentry Performance, SpeedCurve RUM, New Relic Browser.
  - Lab (testy syntetyczne) – powtarzalne testy scenariuszy z ustalonych lokalizacji (Lighthouse CI, WebPageTest, SpeedCurve synthetics).
- Alerty:
  - RUM: alert, gdy odsetek „dobrych” doświadczeń (np. LCP < 2.5 s) spada poniżej progu przez X dni.
  - Lab: alert, gdy LCP dla strony kluczowej (np. landing) rośnie o >20% względem poprzedniej mediany lub przekracza próg.
- Co monitorować stale: waga strony (KB/MB), liczba żądań, TTFB, LCP, INP, CLS osobno dla desktop i mobile.

Razem te cztery warstwy dają Ci obraz: od „czy żyje?”, przez „czy działa?”, po „czy działa szybko i stabilnie?”.

#### Jak ułożyć alerty, żeby nie oszaleć od powiadomień

- Priorytetyzacja
  - Krytyczne (sms/pager): brak odpowiedzi (downtime), skok 5xx, awaria kluczowej ścieżki (checkout, wysyłka formularza lead).
  - Wysokie (Slack/e‑mail natychmiast): nowy błąd JS o wysokiej częstości, spadek RUM LCP/INP poniżej progu przez 24–48 h.
  - Średnie (codzienny digest): powolne pogorszenie metryk, ostrzeżenia z jednego regionu, pojedyncze błędy rzadkich przeglądarek.
- Anty‑szum
  - Reguły „mute” na zaplanowane prace (maintenance windows).
  - Agregacja: zgłaszaj po potwierdzeniu z 2 lokalizacji; łącz podobne alerty w jeden wątek.
  - Czas ciszy: nocne powiadomienia tylko dla krytycznych incydentów.

Celem jest szybka reakcja na to, co naprawdę szkodzi użytkownikom – resztę zbierasz do przeglądu.

#### Procedura szybkiej reakcji: kto, gdzie, w jakiej kolejności

Najlepszy monitoring bez procedury to chaos. Poniżej prosty, sprawdzony schemat „incident response” dla małego zespołu (lub solowo, ale z rolami).

- Role i kontakt
  - On‑call (dyżurny techniczny): odbiera krytyczne alerty 24/7 w wyznaczonych dniach.
  - Właściciel produktu/marketing: decyduje o komunikacji do użytkowników (baner, social, e‑mail).
  - Dev/Ops rezerwowy: jeśli incydent przeciąga się >30 min, dołącza jako wsparcie.
  - Kanały: Slack „#incydent”, telefon/SMS dla krytycznych. Lista numerów w dokumencie operacyjnym i przypięta w Slack.

- Playbook krok po kroku (pierwsze 30–60 minut)
  1) Potwierdź incydent
     - Sprawdź monitoring z drugiej lokalizacji, otwórz stronę przez VPN/4G, odpal syntetyczny test ścieżki.
  2) Ogranicz wpływ („mitigation”)
     - Wdróż stronę statyczną 503 z informacją dla użytkownika, jeśli całość leży.
     - Wyłącz feature flag powodujący błąd; rollback do poprzedniego wydania, jeśli to po wdrożeniu.
     - Dla wydajności: tymczasowo wyłącz ciężkie skrypty (A/B, czat) przez Tag Manager, jeśli blokują LCP/INP.
  3) Zakomunikuj
     - Krótka informacja na stronie statusu lub w bannerze: „Mamy chwilową awarię formularzy. Pracujemy nad rozwiązaniem. Szacowany czas: 30–60 min. W pilnych sprawach: [telefon/e‑mail]”.
     - Wewnętrznie: wątek „#incydent” z opisem: co, kiedy zauważono, ilu użytkowników dotyczy, co robimy teraz.
  4) Diagnoza równoległa
     - Korelacja z czasem wdrożenia (label release), weryfikacja logów 5xx, porównanie ruchu/TTFB, analiza ostatnich zmian w infrastrukturze lub DNS.
     - Dla błędów JS: zobacz najczęstszą przeglądarkę/wersję, reprodukuj błąd, sprawdź feature flags i polyfille.
  5) Decyzja
     - Jeśli problem z kodem – rollback natychmiast, fix po analizie.
     - Jeśli infrastruktura – przełącz na zapasowy węzeł/region, eskaluj do hostingu/CDN.
  6) Zakończenie i weryfikacja
     - Potwierdź w monitoringu powrót do normy (uptime, spadek 5xx, normalizacja LCP/INP).
     - Wyłącz baner/status, zamknij wątek incydentu, zapisz notatkę.

- Post‑mortem (24–72 h później)
  - Krótki raport: przyczyna źródłowa (root cause), wpływ (jak długo, ilu użytkowników, które strony), co zadziałało, co poprawić.
  - Działania zapobiegawcze: testy przedwdrożeniowe, limity zasobów, alerty doprecyzowane, feature flagi na nowe komponenty.

Taki playbook oszczędza nerwy i skraca czas przestoju. Każdy wie, co robić i w jakiej kolejności.

#### Minimalny zestaw narzędzi i ustawień na start

- Uptime: UptimeRobot (free/pro) – 1 min ping, 2 lokalizacje, SMS dla krytycznych.
- Logi/5xx: monitoring z hostingu lub lekkie APM (np. Better Stack Logs, New Relic lite); alert na skok 5xx > X/min.
- JS errors: Sentry – integracja frontu, source maps, alert „nowy błąd o wysokiej częstotliwości” i „skok błędów po release”.
- CWV:
  - RUM: Search Console (Raport Podstawowe wskaźniki internetowe) + opcjonalnie Sentry Performance/SpeedCurve RUM.
  - Lab: harmonogram Lighthouse CI/WebPageTest dla stron: home, top landing, koszyk/lead. Alert >20% pogorszenia LCP/INP.
- Komunikacja: Slack kanał „#incydent”, szablon banera informacyjnego (w CMS) i strona statusu (nawet prosta, ręczna).

To niewielki wysiłek wdrożeniowy, a ogromny skok w kontroli jakości.

#### Najczęstsze błędy i szybkie korekty

- Alert‑spam, który wszyscy ignorują – przegląd reguł, redukcja do „must know”, wprowadzenie priorytetów i maintenance windows.
- Brak source maps w Sentry – włącz, inaczej naprawiasz „w ciemno”.
- Monitorowanie tylko strony głównej – dodaj ścieżki krytyczne (formularz, checkout, logowanie).
- Brak związania błędów z wydaniami – taguj release’y; korelacja „po wdrożeniu” skraca diagnozę.
- Zero komunikacji do użytkowników – przygotuj szablon banera i stronę statusu. Cisza frustruje bardziej niż sam problem.

### Podsumowanie rozdziału

Monitoring i alerting to Twoja siatka bezpieczeństwa po starcie. Uptime pilnuje dostępności, alerty 5xx mówią o problemach backendu, Sentry wyłapuje błędy po stronie przeglądarki, a stały nadzór Core Web Vitals chroni SEO i konwersję przed „powolnym psuciem się” wydajności. Kluczem jest też procedura reakcji: jasne role, kanały, kolejność działań i krótki post‑mortem. Dzięki temu incydenty przestają być kryzysem – stają się epizodem, z którego wyciągasz wnioski. Użytkownik widzi po prostu działającą stronę. A o to właśnie chodzi.